The exemplary embodiment relates to systems and methods for implementing a universal print driver in a Microsoft® Windows® V4 print architecture.
In the field of print driver architectures and platforms, printer manufacturers have long integrated print driver and related software for their particular output devices with commonly available computer operating systems, including the Microsoft® Windows® family of operating systems. In this regard, the Windows® third generation (V3) print architecture includes a software development kit (SDK) for print vendors, which enables them to write software plug-ins to handle many very flexible, low-level callback functions to fully customize the installation, graphical user interface (GUI) and rendering behaviors of a print driver.
A current global print driver (or universal printer driver) for the Microsoft® Windows® third generation (V3) print architecture supports printers and multi-function devices (MFDs). The V3 version of the global print driver (GPD) queries the connected printer across the network to determine its model, capabilities, and constraints. The GPD then uses the callbacks described above to fully virtualize the capabilities of a printer, such as its features and their supported options. The result looks and acts exactly like a traditional model-specific driver for that printer, but is easier for system administrators to manage.
However, starting with the Windows® 8 operating system, Microsoft introduced a new fourth generation (V4) print architecture. Significantly, the callback mechanism to allow a print driver to query device configuration data was eliminated. The only remaining mechanism requires the printing device to support specific protocols. Print drivers declare query strings in data files for use by the operating system but cannot execute the queries themselves. Data files are also used to map query results to installable option states to configure the print driver automatically.
However, many printers (or printing devices) do not support the specific protocols or queries necessary to enable automatic configuration in V4 print drivers for Windows® 8 and future versions of the operating system, and a separate driver is generally required for each model. System administrators would need to manually configure the V4 print driver for every printing device that does not support the specific required protocols and queries, even if a V3 print driver for the same printing device could successfully configure itself.
In addition, it is desirable to provide methods and systems for a universal print driver to not only auto-configure the installable device options, but also to tailor the behavior of the print driver's graphical user interface and its output as extensively as is appropriate for a specific printer model, in a V4 print driver.
Moreover, there is a need for a completely new approach, because the Windows® V4 print architecture eliminated the essential software call-back functions that vendors could use to return dynamically generated printer capabilities specifications and to perform other model-specific tasks. Windows® instead requires V4 drivers to define the capabilities, constraints, etc. of the printer in static data files that must be digitally signed and installed as part of the driver installation package. That requirement makes printer model capabilities virtualization impossible, since the vendor supplied files are processed by Microsoft® code, not vendor code, and are static.